home *** CD-ROM | disk | FTP | other *** search
/ 2,000 Greater & Lesser Mysteries / 2,000 Greater and Lesser Mysteries.iso / computer / virus / mys00448.txt < prev    next >
Encoding:
Text File  |  1994-06-10  |  9.2 KB  |  171 lines

  1.     This was originally posted in the International Virus Echo, but
  2. some parties here may find of interest.
  3.  
  4. Date: 06-30-90 (03:11)     Number: 1344             The DATAMAX BBS
  5.   To: ALL                        Refer#: NONE
  6. From: MARK TAYLOR                  Read: YES
  7. Subj: REPOSTED MESSAGE             Conf: (39) fVIRUS
  8. ------------------------------------------------------------------------
  9. (This message was originally addressed to "Merry Hughes", an alias
  10. used by the sysop of the Excalibur BBS. The author, Frank Breault,
  11. tried to post it there on June 28.  Since he is not a caller of this
  12. BBS, he asked me to repost it for him here because it contains
  13. important information which everyone should be made aware of. Frank
  14. is offering to substantiate his statements in writing in a docu-
  15. mented, scientific way, and to provide samples, copies of work logs,
  16. decrypted virus images and transcripts of debugger sessions to
  17. anyone who is  *NOT CONNECTED*  in any way with the so-called
  18. "researchers" of the McAfee company. A sworn, notarized affidavit
  19. to that effect will be required prior to release of code data or
  20. samples. Leave me a message if you are interested and I'll try to
  21. make arrangements.  I make no claim of any knowledge of these
  22. matters but think that people should be allowed to express the
  23. results of their work, especially when they are trying to warn the
  24. public about a serious possible danger in a selfless, noncommercial
  25. manner). ------Message starts:
  26.  
  27. "Well, Merry, most of those who have looked at this unusual virus
  28. still don't know everything about it.  Even after being fully
  29. decrypted, the code remains hard to disassemble.  But I am certain
  30. that it doesn't contain any reboot routine and I am *quite certain*
  31. that it does not occupy variable memory size.  I have some idea of
  32. how you came to believe that it uses variable memory allocation but,
  33. not knowing exactly what you saw, I can't explain your belief. I
  34. think perhaps you were misled by a trick it plays as it loads into
  35. RAM. Anyway, Dave Chess of IBM stated that he has disassembled
  36. about half of it.  Rick Engle of Wang Labs seems to have decrypted it
  37. almost completely.  The difficulty in disassembling stems from its
  38. intentionally-misleading code.
  39.  
  40. Regarding the reboot, perhaps the protection program you were using
  41. caused it, not the virus itself (Incidentally, both version 1.07 and
  42. v1.10 of the F-DLOCK program you mentioned are quite useless
  43. against the FISH 6: it goes right by them).
  44.  
  45. Every day, I am finding new and intriguing aspects of the FISH 6.
  46. You have no doubt noticed that the virus changes its appearance on
  47. disk each day of the year.  All copies are encrypted, but copies
  48. produced the same day are all encrypted similarly.  This indicates
  49. that the date holds the encryption key and indeed, that turns out to
  50. be so:  the virus looks at the date and adds the number of the month
  51. + the day of the month to derive `n', the number it uses as key for
  52. its disk XORing routine. The encryption routine used on disk and the
  53. one used in memory are not the same, however.
  54.  
  55. I now have a fully-decrypted copy of the FISH 6. The string you
  56. mentioned is shown:
  57.  
  58.  
  59. (Quotation marks are mine).  The entire string is displayed onscreen
  60. if any infected file is executed twice when the system date is 1991.
  61. any sense out of them yet (with my luck, it's probably my birthdate
  62. - or yours!).
  63.  
  64. Once fully decrypted, the virus code is seen to contain the
  65. following strings, scattered all over its body:
  66.  
  67.    FISH, SHAD, TROUT, FIN, MUSKY, SOLE, PIKE, MACKEREL,
  68.    TUNA, CARP, COD, BASS, SHARK.
  69.  
  70. While in RAM, however, they appear only partially decrypted at any
  71. one instant, but this appearance also changes constantly.  Although
  72. obviously fish names, they are probably not true text strings as
  73. such, but portions of executable code.  Did someone take the time to
  74. compose this:
  75.              T = 54h = PUSH SP
  76.              U = 55h = PUSH BP
  77.              N = 4Eh = DEC SI
  78.              A = 41h = INC CX
  79. and then incorporate it into self-encrypting code in some meaningful
  80. manner..?  Are they just decoration..?  Encryption keys..?
  81.  
  82. The RAM image, responsible for the viral activity once the virus is
  83. loaded into memory, is itself also encrypted, but not in the same
  84. manner as on disk. Its appearance seems to change from one moment
  85. to the next.  The virus does this every time Int 21 is called. Such
  86. mutations in RAM do not involve the entire 3584 bytes, but only many
  87. short portions of the code, each 4-5 bytes long, at any given time.
  88. After enough such changes have taken place, the entire body of the
  89. virus in RAM would have been completely altered (except the de-
  90. cryption routine itself).  The size of the memory image, however,
  91. remains definitely constant and *does not change*, as you stated.
  92. You can be assured of that.
  93.  
  94. The string "FISH FI..." is found, as you yourself stated, Merry, at
  95. the end of infected disk files. This, however, is not "later removed
  96. from the file by the virus itself", as you said.  The "FISH FI..."
  97. string is permanent. However, if you try to use it as a signature
  98. for the virus, it isn't always useful.  Perhaps this action of the
  99. virus is what gave you the impression that the string gets removed;
  100. it doesn't, but neither can you read it if the virus is in RAM.  The
  101. string, together with the rest of the virus code, appears to vanish.
  102.  
  103. Like the 4096, the virus disinfects files "on the fly" as these are
  104. loaded into RAM, so they show the original size, date and CRC. The
  105. FISH 6 seems to use an improved technique to do this, however, and
  106. this probably allows it to "disinfect" even files that are being
  107. opened for Read (as when being scanned for search strings).
  108.  
  109. The method used by the FISH 6 to determine which file to "clean up"
  110. (as it's being opened or loaded into RAM) is different from the one
  111. it uses to determine whether a file is already infected (for
  112. purposes of avoiding multiple reinfection). Like the 4096, the FISH
  113. marks infected files by altering a special byte in the file date
  114. entry. (The presence of this "autodisinfection marker" is of limited
  115. diagnostic value; several viruses use it). In the case of the FISH
  116. 6, files bearing this mark are automatically "disinfected" on the
  117. fly when opened.  The virus does not use this modified date entry to
  118. determine which files to infect, in the way Zero Bug, Vienna and
  119. other viruses do. If this byte is altered, the virus stops "auto-
  120. disinfecting" them, but the files remain infected and infectious;
  121. FISH 6 knows this and does not reinfect them a second time. It uses
  122. another method to determine which files it has already infected. I
  123. believe this may be related to certain operations performed at the
  124. very beginning of the virus code.
  125.  
  126.  NOTE: If an infected file is manually re-dated, it will no longer
  127.        be disinfected "on the fly" by the FISH 6. Thus, files whose
  128.        "autodisinfection byte" has been deleted *can be* identified,
  129.        if infected, using string scanners, even if FISH 6 is active
  130.        in RAM.  This offers a means, albeit inelegant, to prepare a
  131.        suspected file for scanning without the virus being able to
  132.        hide itself. If a file is so prepared (redated), then SCANV
  133.        and F-PROT and other string searchers will again be able to
  134.        detect it - but they may still spread the infection in any
  135.        case, if FISH 6 is in RAM.
  136.  
  137.                            WARNING:
  138.                            -------
  139. This virus would seem to encrypt itself in more than one way or, at
  140. least, change in some unusual manner.  I have in my possession
  141. copies of what seems to be the FISH 6 virus, but which do not bear
  142. the scanning string used by SCANV 64 and F-PROT 1.10 and are
  143. *NOT
  144. DETECTED BY EITHER SCANNER* on disk.  Yet, they are active
  145. and give
  146. rise to infections which appear similar to the FISH 6.  In this
  147. sense, I have also received confirmed reports about the existence of
  148. a  "Mother Fish", larger in size and having the capability of
  149. changing the character of the FISH 6 into a different virus. I don't
  150. yet have this "Mother Fish" but wonder if perhaps these strange FISH
  151. copies might have been produced by it, and if the virus which we all
  152. call the "FISH 6" is really not a virus, in the usual sense, but
  153. rather just the end product of a more complex, much more
  154. sophisticated and dangerous viral *system*.  If this is so (and it
  155. appears that it may be so), then analyzing the FISH 6 as a simple
  156. entity might be a serious mistake.
  157. ---------Message ends.
  158.  
  159. Personally, I think it's very regrettable that the people in the
  160. McAfee company are endangering the public by witholding information
  161. just because it does not agree with the results they previously
  162. published in error. How long does everybody have to live under false
  163. assumptions just to allow "Merry Hughes" to save face? When Frank
  164. Breault made a mistake earlier, he admitted it and corrected it
  165. immediately (12 hours later). Why is it that the person who calls
  166. herself (falsely) "Merry Hughes" (and who has made many, many
  167. errors describing viruses!) cannot have the decency to admit
  168. *his/her* mistakes?  Why does he/she hide behind an alias???
  169. Really, there is no REQUIREMENT that he/she be infallible,
  170. just plainly honest would do...
  171.